1.3 - Compte
administrateur :
Sous Unix, le compte administrateur est simple à trouver, c'est le
compte root. Sous Windows, c'est plus complexe. Le nom est souvent
internationalisé: Administrator, Administrateur,... Pour le
reconnaître, il faut chercher un compte dont le RID vaut 500.
1.3.1.A - La voie obscure: Syskey :
Comme les structures du fichier SAM ont été rapidement mises
à jour, Microsoft a décidé de chiffrer par du RC4, au sein
même du fichier, les mots de passe cryptés. On peut remarquer que
les structures des fichiers de mots de passe Unix sont publiques et cela n'a
jamais été considéré comme un problème. Les
mots de passe sont de toute façon déjà cryptés de
manière irréversible, il s'agit là uniquement d'un codage
réversible, une couche de brouillard. Depuis le service pack 3 de NT 4,
l'utilitaire Syskey est fourni dans pour réaliser ce codage. Depuis
Windows 2000, ce chiffrement est activé par défaut. La clé
de codage est
soit présente dans le fichier lui-même en clair,
autrement dit, il n'y a aucune protection,
soit la clé est
stockée dans le fichier SAM mais protégée par une
passphrase, un mot de passe à rallonge. L'administrateur doit entrer ce
mot de passe au démarrage de l'ordinateur pour le débloquer.
soit l'administrateur utilise une disquette pour la stocker auquel cas, il
faut l'utiliser à chaque démarrage de la machine.
Dans la base
de registre, la valeur stockée selon les versions de Windows dans les
clés
\SAM\Domains\Account\F, Security\Policy\SecretEncryptionKey ou,
HKLM\System\CurrentControlSet\Control\Lsa reproduit ces trois
possibilités:
1 - clé dans le registre
2 - clé
protégée par une passphrase
3 - clé sur disquette
La possibilité 1 n'offre aucune sécurité, cela
revient à mettre une serrure en laissant la clé dessus. Les deux
autres empêchent les attaques directes des mot de passe LANMAN et NTML.
Des attaques plus complexes sont toujours possibles. L'algorithme de
chiffrement RC4 est un algorithme de chiffrement par flux utilisant le XOR. Or
dans ce type d'algorithme, le flux de chiffrement ne doit pas être
réutilisé, il ne faut pas chiffrer indépendamment les uns
des autres des blocs de données. Bindview s'est rendu compte en 1999 que
Microsoft l'utilisait (Il l'utilise toujours) pour chiffrer utilisateur par
utilisateur le mot de passe LANMAN puis le mot de passe NTLM. Le flux de
chiffrement généré à partir de la clé RC4 est
donc réutilisé! Cela ouvre donc la voie à des attaques
cryptographiques. La mauvaise implémentation de cet algorithme permet de
vérifier la validité d'un mot de passe d'un utilisateur. Si le XOR
produit par les deux mots de passe chiffrés en RC4 lus dans le fichier
est égale au XOR des mots de passe Lanman et NTLM, bingo, le mot de passe
est trouvé!
Si cette relation est vérifiée, le mot
de passe est trouvé
→ NTLM ?
NTLM chiffré
Mot de passe > Xor = Xor
potentiel
→ LANMAN LANMAN
chiffré
Ainsi des attaques sont toujours réalisables
même si la clé RC4 est inconnue. C'est juste un peu plus lent que
de s'attaquer au chiffrement NTLM directement quand cela était possible
(absence de syskey ou clé syskey connue).